Multipath TCP Subflow Establishment and Control

ABSTRACT

Techniques for electronic devices to control a multipath transmission control protocol (MPTCP) connection. An MPTCP connection between two endpoints may be established. The MPTCP connection may include at least one MPTCP subflow. At least one of the endpoints may be configured to act as a master with respect to the MPTCP connection. The master may perform one or more control operations on the MPTCP connection, while if one of the endpoints is not a master, that endpoint may not perform control operations on the MPTCP connection. The control operations may include initiating or establishing new MPTCP subflows or modifying a priority level of one or more MPTCP subflows of the MPTCP connection.

PRIORITY CLAIM

The present application is a continuation of U.S. patent applicationSer. No. 15/928,664, entitled “Multipath TCP Subflow Establishment andControl”, filed Mar. 22, 2018, which is a continuation of U.S. patentapplication Ser. No. 15/253,441, entitled “Multipath TCP SubflowEstablishment and Control”, filed Aug. 31, 2016, which is a continuationof U.S. patent application Ser. No. 13/911,759, entitled “Multipath TCPSubflow Establishment and Control”, filed Jun. 6, 2013, which are allhereby incorporated by reference in their entirety as though fully andcompletely set forth herein.

The claims in the instant application are different than those of theparent application or other related applications. The Applicanttherefore rescinds any disclaimer of claim scope made in the parentapplication or any predecessor application in relation to the instantapplication. The Examiner is therefore advised that any such previousdisclaimer and the cited references that it was made to avoid, may needto be revisited. Further, any disclaimer made in the instant applicationshould not be read into or against the parent application or otherrelated applications.

FIELD

The present disclosure relates to electronic devices, and moreparticularly to a system and method for a wireless device to establishand control multipath TCP subflows.

DESCRIPTION OF THE RELATED ART

Wireless communication systems are rapidly growing in usage.Additionally, there exist numerous different wireless communicationtechnologies and standards. Some examples of wireless communicationstandards include GSM, UMTS (WCDMA), LTE, LTE Advanced (LTE-A), 3GPP2CDMA2000 (e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), IEEE 802.11 (WLAN orWi-Fi), IEEE 802.16 (WiMAX), Bluetooth, and others.

Some of these standards may serve complementary functions while othersmay typically be considered competitors attempting to fulfill similarneeds amongst consumers. Accordingly, it is common for at least somewireless devices to communicate using multiple wireless technologies orstandards. For example, some wireless devices (such as some smartphones, etc.), may be capable of cellular communication as well as Wi-Ficommunication.

SUMMARY

Embodiments are presented herein of a method for an electronic device toestablish and configure control of multipath TCP (MPTCP) connections andsubflows, and an electronic device configured to implement the method.

Techniques for establishing MPTCP connections are described herein,which may take into consideration disparate characteristics of differenttypes of network interfaces. For example, it is noted that many wireless(e.g., mobile) devices may include both Wi-Fi and cellular networkinterfaces capable of providing data links, while many servers (andother fixed/stationary devices) may primarily or exclusively includewired network interfaces.

Since different network interfaces may have different availabilities,and use preferences with respect to different network interfaces maygenerally differ, according to some of the techniques presented herein adevice may monitor the availability of its network interfaces and/orconsider network interface use preferences specific to the device orclass of device in determining how and in what order to attempt toestablish a MPTCP connection.

Also described herein are techniques for controlling an MPTCPconnection. Again considering the disparate characteristics of differenttypes of network interfaces and devices which implement those varioustypes of network interfaces, according to some of the techniquespresented herein a device may assert controllership/declare itself to bea master with respect to an MPTCP connection, or in contrast, may assertnon-controllership/declare itself to be a slave with respect to an MPTCPconnection. In such a way, devices which have stronger network interfaceuse preferences (such as mobile devices, in some cases) may control anMPTCP connection in accordance with their network interface usepreferences, while devices with weaker or nonexistent network interfaceuse preferences (such as fixed/stationary devices, in some cases) mayavoid unintentionally violating the network interface use preferences ofdevices with which they establish MPTCP connections.

In assuming roles as master or slave with respect to an MPTCPconnection, devices may either assume or relinquish the capability toperform certain control operations on the MPTCP connection. For example,permission to initiate any new MPTCP subflows of an MPTCP connection maybe reserved for devices which assume a master role with respect to anMPTCP connection. As another example, permission to modify prioritylevels of MPTCP subflows of an MPTCP connection may be reserved fordevices which assume a master role with respect to an MPTCP connection.

The techniques described herein may be implemented in and/or used with anumber of different types of devices, including but not limited toportable media players, cellular phones, tablet computers, set top boxdevices, television systems, servers, and other computing devices.

This Summary is intended to provide a brief overview of some of thesubject matter described in this document. Accordingly, it will beappreciated that the above-described features are merely examples andshould not be construed to narrow the scope or spirit of the subjectmatter described herein in any way. Other features, aspects, andadvantages of the subject matter described herein will become apparentfrom the following Detailed Description, Figures, and Claims.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present subject matter can be obtainedwhen the following detailed description of the preferred embodiment isconsidered in conjunction with the following drawings, in which:

FIGS. 1-2 illustrate exemplary (and simplified) wireless communicationsystems;

FIG. 3 illustrates a cellular base station and a Wi-Fi access point incommunication with a wireless user equipment device;

FIG. 4 illustrates an exemplary block diagram of a wireless userequipment device;

FIG. 5 illustrates an exemplary protocol stack which may be used inconjunction with multipath transmission control protocol communications;

FIG. 6 is a flowchart diagram illustrating aspects of a technique forestablishing an MPTCP connection;

FIG. 7 is a message sequence chart illustrating an exemplary messagesequence which may be used as part of establishing an MPTCP connection;and

FIGS. 8 and 9 illustrate exemplary MP_Capable option formats.

While the features described herein are susceptible to variousmodifications and alternative forms, specific embodiments thereof areshown by way of example in the drawings and are herein described indetail. It should be understood, however, that the drawings and detaileddescription thereto are not intended to be limiting to the particularform disclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the subject matter as defined by the appended claims.

DETAILED DESCRIPTION OF THE EMBODIMENTS Terms

The following is a glossary of terms used in the present disclosure:

Memory Medium—Any of various types of memory devices or storage devices.The term “memory medium” is intended to include an installation medium,e.g., a CD-ROM, floppy disks, or tape device; a computer system memoryor random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, RambusRAM, etc.; a non-volatile memory such as a Flash, magnetic media, e.g.,a hard drive, or optical storage; registers, or other similar types ofmemory elements, etc. The memory medium may include other types ofmemory as well or combinations thereof. In addition, the memory mediummay be located in a first computer system in which the programs areexecuted, or may be located in a second different computer system whichconnects to the first computer system over a network, such as theInternet. In the latter instance, the second computer system may provideprogram instructions to the first computer for execution. The term“memory medium” may include two or more memory mediums which may residein different locations, e.g., in different computer systems that areconnected over a network. The memory medium may store programinstructions (e.g., embodied as computer programs) that may be executedby one or more processors.

Carrier Medium—a memory medium as described above, as well as a physicaltransmission medium, such as a bus, network, and/or other physicaltransmission medium that conveys signals such as electrical,electromagnetic, or digital signals.

Programmable Hardware Element—includes various hardware devicescomprising multiple programmable function blocks connected via aprogrammable interconnect. Examples include FPGAs (Field ProgrammableGate Arrays), PLDs (Programmable Logic Devices), FPOAs (FieldProgrammable Object Arrays), and CPLDs (Complex PLDs). The programmablefunction blocks may range from fine grained (combinatorial logic or lookup tables) to coarse grained (arithmetic logic units or processorcores). A programmable hardware element may also be referred to as“reconfigurable logic”.

Computer System—any of various types of computing or processing systems,including a personal computer system (PC), mainframe computer system,workstation, network appliance, Internet appliance, personal digitalassistant (PDA), personal communication device, smart phone, televisionsystem, grid computing system, or other device or combinations ofdevices. In general, the term “computer system” can be broadly definedto encompass any device (or combination of devices) having at least oneprocessor that executes instructions from a memory medium.

User Equipment (UE) (or “UE Device”)—any of various types of computersystems devices which are mobile or portable and which performs wirelesscommunications. Examples of UE devices include mobile telephones orsmart phones (e.g., iPhone™, Android™-based phones), portable gamingdevices (e.g., Nintendo DS™, PlayStation Portable™, Gameboy Advance™,iPhone™), laptops, PDAs, portable Internet devices, music players, datastorage devices, or other handheld devices, etc. In general, the term“UE” or “UE device” can be broadly defined to encompass any electronic,computing, and/or telecommunications device (or combination of devices)which is easily transported by a user and capable of wirelesscommunication.

Base Station—The term “Base Station” has the full breadth of itsordinary meaning, and at least includes a wireless communication stationinstalled at a fixed location and used to communicate as part of awireless telephone system or radio system.

Processing Element—refers to various elements or combinations ofelements. Processing elements include, for example, circuits such as anASIC (Application Specific Integrated Circuit), portions or circuits ofindividual processor cores, entire processor cores, individualprocessors, programmable hardware devices such as a field programmablegate array (FPGA), and/or larger portions of systems that includemultiple processors.

Automatically—refers to an action or operation performed by a computersystem (e.g., software executed by the computer system) or device (e.g.,circuitry, programmable hardware elements, ASICs, etc.), without userinput directly specifying or performing the action or operation. Thusthe term “automatically” is in contrast to an operation being manuallyperformed or specified by the user, where the user provides input todirectly perform the operation. An automatic procedure may be initiatedby input provided by the user, but the subsequent actions that areperformed “automatically” are not specified by the user, i.e., are notperformed “manually”, where the user specifies each action to perform.For example, a user filling out an electronic form by selecting eachfield and providing input specifying information (e.g., by typinginformation, selecting check boxes, radio selections, etc.) is fillingout the form manually, even though the computer system must update theform in response to the user actions. The form may be automaticallyfilled out by the computer system where the computer system (e.g.,software executing on the computer system) analyzes the fields of theform and fills in the form without any user input specifying the answersto the fields. As indicated above, the user may invoke the automaticfilling of the form, but is not involved in the actual filling of theform (e.g., the user is not manually specifying answers to fields butrather they are being automatically completed). The presentspecification provides various examples of operations beingautomatically performed in response to actions the user has taken.

FIGS. 1-2—Communication System

FIGS. 1-2 illustrate exemplary (and simplified) communication systems.It is noted that the systems of FIGS. 1-2 are merely examples ofpossible systems, and embodiments may be implemented in any of varioussystems, as desired.

The exemplary wireless communication system illustrated in FIG. 1includes two endpoints having multiple communication paths between them.Thus, endpoint 102 may be capable of communicating with endpoint 104 viapath 106 or path 108.

Each of endpoint 102 and endpoint 104 may be a ‘fixed’ or ‘mobile’endpoint. A fixed endpoint may be an endpoint which is substantiallystationary and/or which communicates by way of one or more wiredcommunication techniques. Some examples might include a server computerproviding cloud-based services via the Internet, a personal desktopcomputer or workstation, set top box or television, etc. A mobileendpoint may be an endpoint which is substantially mobile and/or whichcommunicates by way of one or more wireless communication techniques.Some examples might include a mobile telephone or smart phone, tabletcomputer, portable gaming device, portable media player, etc. Note thathybrid endpoints which share traits of both fixed and mobile endpointsare also possible. For example, many laptop computers may be capable ofperforming both wireless (e.g., Wi-Fi) and wired (e.g., Ethernet)communication, and additionally may be capable of substantial movement(e.g., when operating from batter reserve power) or may be substantiallystationary (e.g., when docked and/or connected to a wall outlet forpower) at various times.

One or both of endpoints 102, 104 may be multihomed. For example, one orboth of endpoint 102, 104 may be capable of communicating via multiplenetwork interfaces. As such, there may be multiple possiblecommunication paths 106, 108 between endpoints 102, 104. Note thatalthough two paths (i.e., path 106 and path 108) are illustrated in FIG.1, it should be noted that any number of paths may exist betweenendpoints. For example, if each of endpoints 102, 104 are capable ofcommunicating via two different network interfaces, there might be fourpossible communication paths between them. Other numbers of differentnetwork interfaces and possible communication paths are also possible.

The multiple communication paths 106, 108 may be used to establish amultipath transmission control protocol (MPTCP) link or connectionbetween endpoints 102 and 104. For example, one subflow of the MPTCPconnection may be established over path 106, while another subflow ofthe MPTCP connection may be established over path 108. Such an MPTCPconnection may be established and configured/controlled according tovarious aspects of the present disclosure.

The exemplary wireless communication system illustrated in FIG. 2represents one possible communication system having the characteristicsof the exemplary wireless communication system illustrated in FIG. 1. Inparticular, a first endpoint (i.e., a wireless user equipment (“UE”)device 206) may be capable of communicating with another endpoint (i.e.,server 210) using either of a first communication path (i.e., viacellular base station 204, core network 208, and wide area network 200)or a second communication path (i.e., via Wi-Fi access point 202 andwide area network 200).

As shown, the UE device 206 communicates with a Wi-Fi access point 202and with a cellular base station 204. The access point 202 may be anaccess point providing a wireless local area network (WLAN). The accesspoint 202 may be equipped to communicate with a wide area network (WAN)200, such as the Internet. Thus, the access point 202 may facilitatecommunication between the UE 206 and the network 200. The access point202 and the UE 206 may be configured to communicate over thetransmission medium using Wi-Fi, including any of various versions ofIEEE 802.11 (e.g., a, b, g, n, ac, etc.). Note that the access point 202may also facilitate communication between the UE and other computingdevices which also participate in the WLAN directly.

The base station 204 may be a base transceiver station (BTS) or cellsite (a “cellular base station”), and may include hardware that enableswireless communication with cellular devices (such as UE 206) accordingto one or more cellular communication protocols. The UE 206 and thecellular base station 204 may communicate using any of various cellularcommunication technologies such as GSM, UMTS (WCDMA), LTE, LTE-Advanced(LTE-A), 3GPP2 CDMA2000 (e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), etc.

As shown, the cellular base station may be equipped to communicate witha core network 208 of a cellular service provider. Thus, the basestation 204 may facilitate communication between the UE 206 and the corenetwork 208. The core network 208 may in turn be equipped to communicatewith WAN 200 (e.g., the Internet, or another wide area network). Notethat the core network 208 may also or alternatively be equipped tocommunicate with one or more other networks (e.g., a telecommunicationnetwork such as a public switched telephone network (PSTN), one or morecore networks of other cellular service providers, etc.). The cellularbase station 204 may thus provide the UE 206 (and potentially numerousother UEs) with various telecommunication capabilities, such as voiceand SMS services (e.g., typically via circuit-switched wireless links)and/or data services (e.g., typically via packet-switched wirelesslinks).

Thus, UE 206 may be capable of communicating using multiple wirelesscommunication standards, including at least one wireless networkingprotocol (e.g., Wi-Fi) and at least one cellular communication protocol(e.g., GSM, UMTS (WCDMA), LTE, LTE-Advanced (LTE-A), 3GPP2 CDMA2000(e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), etc.). Note additionally that theUE 206 may also or alternatively be configured to communicate using oneor more global navigational satellite systems (GNSS, e.g., GPS orGLONASS), one or more mobile television broadcasting standards (e.g.,ATSC-M/H or DVB-H), and/or any other wireless communication protocol, ifdesired. In addition, or as an alternative, the UE 106 may be capable ofcommunicating using one or more wired communication standards. Forexample, the UE 206 may be capable of communicating with one or morewired access points, e.g., via Ethernet. It may, for example, bepossible for the UE 206 to couple via wired means to the Wi-Fi accesspoint 202 in addition to or as an alternative to utilizing Wi-Ficommunication. Other combinations of wireless and wired communicationstandards (including more than two wireless and/or wired communicationstandards) are also possible.

The server 210 may also be equipped to communicate with WAN 200. Theserver 210 may, for example, be a server in a server farm configured toprovide a cloud-based service via the Internet. It should be noted thatwhile the server 210 is shown as being directly connected to WAN 200, itmay be the case that the server 210 is connected to the WAN 200 by oneor more intermediary devices and/or entities, such as gateways, routers,firewalls, and/or any of various other “middleboxes”. In addition, itshould be noted that while not explicitly shown, the server 210 mayinclude any number of network interfaces for connecting to the WAN 200,including one or more wired network interfaces and/or one or morewireless network interfaces.

FIG. 3 illustrates the UE device 206 in communication with the cellularbase station 204 and the Wi-Fi access point 202. The UE 106 may be adevice with multiple wireless network connectivity such as a mobilephone, a hand-held device, a computer or a tablet, or virtually any typeof wireless device.

The UE 206 may include a processor that is configured to execute programinstructions stored in memory. The UE 206 may perform any of the methodembodiments described herein by executing such stored instructions.Alternatively, or in addition, the UE 206 may include a programmablehardware element such as an FPGA (field-programmable gate array) that isconfigured to perform any of the method embodiments described herein, orany portion of any of the method embodiments described herein.

The UE 206 may be configured to communicate using any of multiplewireless communication protocols. For example, the UE 206 may beconfigured to communicate using at least one cellular communicationprotocol (such as CDMA2000, LTE, LTE-A, etc.) and Wi-Fi. Othercombinations of wireless and/or wired communication standards are alsopossible.

The UE 206 may include one or more antennas for communicating using oneor more wireless communication protocols. The UE 206 may share one ormore parts of a receive and/or transmit chain between multiple wirelesscommunication standards; for example, the UE 206 might be configured tocommunicate using either of CDMA2000 (1×RTT/1×EV-DO/HRPD/eHRPD) or LTEusing partially or entirely shared wireless communication circuitry(e.g., using a shared radio or at least shared radio components). Theshared communication circuitry may include a single antenna, or mayinclude multiple antennas (e.g., for MIMO) for performing wirelesscommunications. Alternatively, the UE 206 may include separate transmitand/or receive chains (e.g., including separate antennas and other radiocomponents) for each wireless communication protocol with which it isconfigured to communicate. As a further possibility, the UE 206 mayinclude one or more radios or radio components which are shared betweenmultiple wireless communication protocols, and one or more radios orradio components which are used exclusively by a single wirelesscommunication protocol. For example, the UE 206 might include a sharedradio for communicating using either of LTE or CDMA2000 1×RTT, andseparate radios for communicating using each of Wi-Fi and Bluetooth.Other configurations are also possible.

FIG. 4—Exemplary Block Diagram of a UE

FIG. 4 illustrates an exemplary block diagram of a UE 206. As shown, theUE 206 may include a system on chip (SOC) 400, which may includeportions for various purposes. For example, as shown, the SOC 400 mayinclude processor(s) 402 which may execute program instructions for theUE 206 and display circuitry 404 which may perform graphics processingand provide display signals to the display 460. The processor(s) 402 mayalso be coupled to memory management unit (MMU) 440, which may beconfigured to receive addresses from the processor(s) 402 and translatethose addresses to locations in memory (e.g., memory 406, read onlymemory (ROM) 450, NAND flash memory 410) and/or to other circuits ordevices, such as the display circuitry 404, wireless communicationcircuitry 430 (also referred to as a “radio”), connector I/F 420, and/ordisplay 460. The MMU 440 may be configured to perform memory protectionand page table translation or set up. In some embodiments, the MMU 440may be included as a portion of the processor(s) 402.

As shown, the SOC 400 may be coupled to various other circuits of the UE206. For example, the UE 206 may include various types of memory (e.g.,including NAND flash 410), a connector interface 420 (e.g., for couplingto a computer system, dock, charging station, etc.), the display 460,and wireless communication circuitry (or “radio”) 430 (e.g., for LTE,LTE-A, CDMA2000, Bluetooth, Wi-Fi, GPS, etc.).

As noted above, the UE 206 may be configured to communicate wirelesslyusing multiple wireless communication standards. As further noted above,in such instances, the wireless communication circuitry (radio(s)) 430may include radio components which are shared between multiple wirelesscommunication standards and/or radio components which are configuredexclusively for use according to a single wireless communicationstandard. As shown, the UE device 206 may include at least one antenna(and possibly multiple antennas, e.g., for MIMO and/or for implementingdifferent wireless communication technologies, among variouspossibilities), for performing wireless communication with basestations, access points, and/or other devices. For example, the UEdevice 206 may use antenna 435 to perform the wireless communication.

The UE 206 may also include and/or be configured for use with one ormore user interface elements. The user interface elements may includeany of various elements, such as display 460 (which may be a touchscreendisplay), a keyboard (which may be a discrete keyboard or may beimplemented as part of a touchscreen display), a mouse, a microphoneand/or speakers, one or more cameras, one or more buttons, and/or any ofvarious other elements capable of providing information to a user and/orreceiving/interpreting user input.

As described herein, the UE 206 may include hardware and softwarecomponents for implementing features for establishing and/or controllingMPTCP connections, such as those described herein with reference to,inter alia, FIGS. 5-7. The processor 402 of the UE device 206 may beconfigured to implement part or all of the features described herein,e.g., by executing program instructions stored on a memory medium (e.g.,a non-transitory computer-readable memory medium). Alternatively (or inaddition), processor 402 may be configured as a programmable hardwareelement, such as an FPGA (Field Programmable Gate Array), or as an ASIC(Application Specific Integrated Circuit). Alternatively (or inaddition) the processor 402 of the UE device 206, in conjunction withone or more of the other components 400, 404, 406, 410, 420, 430, 435,440, 450, 460 may be configured to implement part or all of the featuresdescribed herein, such as the features described herein with referenceto, inter alia, FIGS. 5-7.

FIG. 5—MPTCP Capable Protocol Stack

FIG. 5 illustrates an exemplary protocol stack which may be used by a UE500 to establish, configure, and control MPTCP connections and subflowsbetween the UE 500 and a server 518, by way of a middlebox 516,according to various aspects of the present disclosure. It should berecognized that while the exemplary protocol stack illustrated in FIG. 5represents one possible protocol stack which may be used to implementaspects of the present disclosure, MPTCP connections and subflows may beestablished, configured, and/or controlled in conjunction with any ofnumerous alternate protocol stacks, in conjunction with differentdevices than UE 500 and server 518, and/or without an intermediarymiddlebox 516 (or with multiple middleboxes). As such, the exemplaryprotocol stack illustrated in FIG. 5 should not be considered limitingto the disclosure as a whole.

As shown, a networking application 502 may be executing on the UE 500.The networking application may be any application which utilizes anetwork connection to communicate over a network. For example, theapplication (or “app”) 502 may be a browser application, emailapplication, chat application, social media application, music serviceapplication, game application, intelligent personal assistantapplication, and/or any of a variety of other types of networkingapplications.

The networking application 502 may interface with a networking framework504, which may be provided by an operating system executing on the UE500. The networking framework 504 may provide a level of abstractionbetween the application 502 and the lower level networking functionalityprovided by the UE 500. The networking framework 504 may in turninterface with a TCP connection library entity 506. The TCP connectionlibrary 506 may have knowledge of the status of various networkinterfaces, by way of communication with a network interface statusentity 508.

The network interface status entity 508 may monitor the up/down statusand support network interface upkeep of various network interfacesavailable to the UE 500. Information regarding the status of the variousnetwork interfaces available to the UE 500 may be particularly helpfulfor a mobile device which is capable of utilizing one or more forms ofwireless communication, such as cellular communication and Wi-Fi. Forexample, the network interface status entity 508 may be aware of whetheror not a cellular data link is available at any given time, and maysimilarly be aware of whether or not a Wi-Fi link is available at anygiven time. The network interface status entity 508 may similarlymonitor any additional or alternative network interfaces as well. Insome cases the network interface status entity 508 may also be aware ofany further considerations relating to various available networkinterfaces, such as network interface use preferences. For example, formany mobile devices, Wi-Fi data communication may be less expensive thancellular data communication (e.g., if a cellular service provider offersmetered data usage while a Wi-Fi service provider offers unmetered datausage); in such a case, a preference to use a Wi-Fi network interfacerather than a cellular network interface for data communication whenpossible may be noted by the network interface status entity 508 in theUE 500. Other preferences or considerations may also or alternatively bestored.

Being aware of such information by way of its communication with thenetwork interface status entity 508, then, the TCP connection library506 may act as a transport connection manager and intelligently manageTCP connections for the networking application 502. For example, the TCPconnection library 506 may be capable of initiating and tearing down TCPconnections (including MPTCP subflows) with networked entities (such asserver 518) via various network interfaces, establishing and/ormodifying MPTCP subflow priorities, and asserting control over MPTCPsubflow creation and priority status modification, such as describedfurther subsequently herein. The TCP connection library 506 may do so byway of socket layers BSD socket 510, MPTCP socket 512, and TCPconnection/subflows 514.

As shown, the resulting MPTCP subflows may be established as part of anMPTCP connection with the server 518 by way of the middlebox 516. Themiddlebox 516 may include any of a variety of types of middleboxfunctionality, such as a firewall, load balancing, network addresstranslation, etc. Note that in some cases (e.g., depending on middleboxfunctionality), an MPTCP connection may be terminated at the middlebox516, which may in turn route data to server 518 in a separate connection(e.g., according to a load balancing algorithm within a server farm).

FIG. 6—MPTCP Subflow Establishment Flowchart

FIG. 6 is a flowchart diagram illustrating an exemplary MPTCPestablishment process. The process illustrated in FIG. 6 mayparticularly be of use for mobile devices (e.g., devices such as the UE206 illustrated in FIGS. 2-4 and the UE 500 illustrated in FIG. 5). Forexample, as previously noted, for many such devices, use of a Wi-Fi datalink may be preferable for network communications when available becausedata usage may be unmetered for many Wi-Fi data links, while use of acellular data link may be preferable for network communications as abackup (e.g., when Wi-Fi and/or other network interfaces areunavailable) because data usage may be metered for many cellular datalinks. Accordingly, the exemplary MPTCP establishment process may set upan MPTCP connection by first and preferentially attempting to establisha Wi-Fi MPTCP subflow, and subsequently/secondarily attempting toestablish a cellular MPTCP subflow if possible.

The method shown in FIG. 6 may be used in conjunction with any of thecomputer systems or devices shown in the above Figures, among otherdevices. Some of the method elements shown may be performedconcurrently, in a different order than shown, or may be omitted.Additional method elements may also be performed as desired. As shown,the method may operate as follows.

In 602, an MPTCP session may be initiated at a device. The MPTCP sessionmay be initiated as part of operation of a networking application (e.g.,such as networking application 502 illustrated in FIG. 5). The MPTCPsession may be intended to provide at least one, and preferably multiplecommunication paths between a first device and a second device in theform of a MPTCP connection. Particularly for a wireless device,establishing multiple communication paths may be desirable in order toprovide increased resiliency, e.g., in case one of the communicationpaths fails (as wireless links sometimes do, particularly under mobileconditions) or is removed. The MPTCP session may be managed by a TCPconnection management entity executing on the device, such as the TCPconnection library 506 illustrated in FIG. 5.

In 604, it may be determined whether or not a Wi-Fi data link ispresent. Wi-Fi may be present, for example, if the device is withinrange of a Wi-Fi access point and the device is configured tocommunicate with the Wi-Fi access point, such as if the device islocated in the home of a user of the device, in a café which has a knownWi-Fi hotspot, in a workplace with a Wi-Fi network, etc. However, inmany cases, such as if a user of the device is travelling and is eithernot within communicative range of any Wi-Fi networks or is notconfigured to communicate with (e.g., is not a member of) any Wi-Finetworks within communicative range, no Wi-Fi data link may be present.As another possibility, a Wi-Fi data link may not be present if a userof the device has configured the device to power down its Wi-Fi radio.

If a Wi-fi data link is not present, in 606 it may be determined whetheror not a cellular data link is present. A cellular data link may bepresent, for example, if the device is within communicative range of abase station which is capable of providing cellular service (e.g., whichmay depend on the cellular technology capabilities of the device and thebase station, and/or the cellular service provider of the device andoperator of the base station). Although cellular networks may typicallyprovide much broader coverage than Wi-Fi networks, in some cases it isalso possible that no cellular data link is present, such as if a userof the device is in a remote area which is out of communicative range ofany base station or is not configured to communicate with (e.g., is nota subscriber of) any cellular networks within communicative range.Additionally, it may also be possible that a cellular data link may notbe present if a user of the device has configured the device to powerdown its cellular radio.

If neither a Wi-Fi data link nor a cellular data link is available, in608 it may be determined that the Internet is unavailable at that time.In this case it may not be possible to establish the desired MPTCPsession at that time.

If a Wi-Fi data link is present in decision 604, or if no Wi-Fi datalink is present in decision 604 but a cellular data link is present indecision 606, in 610 an attempt to establish a first MPTCP subflow maybe made. Depending on whether arrived from decision 604 or decision 606,the attempt may be made either on the Wi-Fi data link or the cellulardata link.

In 612 it may be determined if the subflow was successfully establishedas an MPTCP subflow. If the subflow was successfully established as anMPTCP subflow, in 614, read/writes may be performed over the firstsubflow. If, however, MPTCP negotiation fails, the connection may fallback to regular TCP in 616. If the regular TCP connection issuccessfully established, in 618 read/writes may be performed overregular TCP until the end of the session at 620.

If both MPTCP and TCP connections fail to be negotiated during anattempt to establish a subflow over Wi-Fi, in 622 a cellular fallbackfeature may be initiated and, returning to step 610, an attempt toestablish an MPTCP subflow over a cellular data link may be performed.If no cellular data link is present when attempting the cellularfallback in step 622, it may be determined in 624 (similar to step 608)that the Internet is unavailable at that time.

Otherwise, a cellular fallback attempt to establish a first MPTCPsubflow may follow a similar workflow as an attempt to establish a firstMPTCP subflow over a Wi-Fi data link.

Once a first MPTCP subflow is established (e.g., over Wi-Fi or overcellular) and read/writes are being performed over the first subflow in614, it may be determined whether or not the read/writes over theestablished MPTCP subflow are successful in 626. As described furthersubsequently herein with respect to FIG. 7, it may be possible that evenif the first subflow is apparently established as an MPTCP subflow,attempted read and/or write operations on the MPTCP subflow may notsuccessfully retain MPTCP characteristics. In this case, in 628 theread/write operations may either be successful as a regular TCPconnection (TCP fallback), or may be unsuccessful altogether. Iffallback to a regular TCP connection is successful, in 630 read/writesmay be performed over regular TCP until the end of the session at 620.If fallback to a regular TCP connection is unsuccessful, in 632 thesession may be aborted as unsuccessful.

If, however, in 626 it is determined that at least one read and/or writeoperation is successful as an MPTCP subflow, in 634 it may be determinedwhether another network interface is available. Thus, for example, ifthe first subflow is over a Wi-Fi data link, and a cellular data link isalso available, in 636 another MPTCP subflow may be initiated on thecellular data link. Similarly, if the first subflow is over a cellulardata link (e.g., if no Wi-Fi was available or subflow setup over Wi-Fiwas unsuccessful), and another network interface is also available(e.g., if a Wi-Fi data link has become available, if the device has afurther network interface available, or simply as another attempt on anavailable Wi-Fi data link on which a previous unsuccessful attempt atMPTCP subflow establishment and/or single flow TCP connectionestablishment was made), in 636 another MPTCP subflow may be initiatedon the selected network interface. If, at decision 638, establishing theadditional subflow is successful, the session (i.e., the MPTCPconnection started in 602) may include performing read and/or writeoperations over multiple subflows at 640. If, at decision 638,establishing the additional subflow is unsuccessful, returning to 620,read and/or write operations may be performed only on the successfullyestablished subflow until the session ends.

As shown, it is also possible that during a session with at least oneactive, established subflow, subflow disconnection may occur. Forexample, a user might move the device out of communicative range of aWi-Fi access point and thereby lose connectivity on their Wi-Fi datalink. In such a case (e.g., from steps 618 or 640 to step 642 via block‘B’), IP address loss may occur and TCP retransmission attempts may failon the disconnected subflow. It may then be determined in 644 if analternate path (e.g., another MPTCP subflow) is present. If an alternatepath is present, in 646 failover to another subflow may occur. Thus inthe above-described exemplary case in which connectivity is lost on aWi-Fi data link, if an MPTCP subflow on a cellular data link has beenestablished, failover to the cellular subflow may occur, and any read orwrite operations occurring as part of the session may be performed overthat subflow, at least until an additional MPTCP subflow can bere-established. If, however, no alternate path is present at decision644, the session may be aborted at 648, as no TCP connection may beavailable at that time.

FIG. 7—Subflow Establishment Message Sequence Chart

FIG. 7 is a message sequence chart illustrating an exemplary messagesequence flow between endpoints attempting to set up an MPTCP sessionwith each other via multiple communication paths. In particular, oneendpoint, as the endpoint initiating the MPTCP connection, may act as anMPTCP client 702, while the other endpoint may act as the MPTCP server704. The client 702 may have both a cellular data link as a firstnetwork interface and a Wi-Fi data link as a second network interface.

The method shown in FIG. 7 may be used in conjunction with any of thecomputer systems or devices shown in the above Figures, among otherdevices. For example, as one possibility, the client 702 may be awireless user equipment (UE) device such as UE 206 and/or UE 500, whilethe server might be server 210 and/or server 518, illustrated in anddescribed with respect to various of the above Figures. More generally,either or both of the client 702 and the server 704 may be ‘fixed’ or‘mobile’ endpoints.

Note additionally that some of the messages shown may be transmittedconcurrently, in a different order than shown, or may be omitted.Additional messages may also be transmitted as desired. As shown, thesequence may operate according to the following flow.

The client 702 may transmit a Syn message 706 to the server 704 as thefirst part of a three phase handshake process/connection establishmentprocedure. As shown, the Syn message 706 may include an MP_Capableoption to indicate that the client 702 is requesting establishment of anMPTCP connection rather than a standard (single-path) TCP connection.

If the server 704 is MPTCP capable and no middlebox has dropped ormodified the Syn message to remove the MP_Capable option (for example,replaced the MP options with no-operations/NOPs), the server 704 maytransmit a Syn_Ack message 708 with an MP_Capable option to indicatethat the server 704 acknowledges the MPTCP request of the client 702 andto indicate that the server 704 is also MPTCP capable.

Again if no middlebox has dropped or modified the Syn_Ack message toremove the MP_Capable option, the client 702 may transmit an Ack message710 to the server 704. The Ack message 710 may also include one or morekeys (e.g., for use in authenticating the addition of future subflows tothe MPTCP connection), as shown.

Note that if the MP_Capable option is dropped (e.g., by a middlebox)from one or both of the Syn message 706 or the Syn_Ack message 708, butthose messages are otherwise delivered intact, the TCP connection maycontinue to be established as a standard (single-path) TCP connectionwithout any additional delay caused by attempting to establish the TCPconnection as an MPTCP subflow. If one or both of the Syn message 706 orthe Syn_Ack message 708 are dropped, the client 702 may attempt toretransmit Syn messages with MPTCP options n (being a configurable orpredetermined number) times, and then if connection establishment isstill unsuccessful, further Syn retransmissions may be made withoutMPTCP options to fall back to a standard TCP connection. In this case, acertain amount of time (e.g., the amount of time associated with the nretransmission attempts with MPTCP options) may be added to the setuptime of the single-path TCP connection.

Once the three-phase MPTCP handshake procedure is successfully completedwith the Ack message 710, the client 702 may attempt to transmit datapackets 712 over the established MPTCP subflow. As part of an MPTCPsubflow, the data packets 712 may include an MP_DSS (data sequencesignal) option.

The server 704 may in turn transmit an Ack message 714 with an MP_DSSoption in response to the data packets 712. The server may additionallytransmit its own data packets 716 to the client 702 over the establishedMPTCP subflow. These packets 716 may also include an MP_DSS option.

Note that even after a TCP handshake procedure is successfullynegotiated with MPTCP options, it may still be possible for a middleboxto drop the MP_DSS option on data or acknowledgement packets. If thisoccurs, the connection may fall back to a standard TCP connection.

Also, for this reason, the client 702 may wait until after anacknowledgement to at least one data packet with an MP_DSS option, whichitself has an MP_DSS option, such as Ack message 714, is received beforeattempting to establish a second MPTCP subflow.

If a TCP handshake procedure is successfully negotiated with MPTCPoptions, and at least one successful read or write operation isperformed (i.e., at least one data packet and ACK are successfullytransmitted) with MPTCP options intact, and the client 702 has acellular data link available in addition to the Wi-Fi data link, theclient 702 may transmit a Syn message 718 to the server 704 by way ofits cellular network interface in order to initiate a handshakeprocedure to attempt to establish another subflow of the MPTCPconnection. As an additional subflow of an existing MPTCP connection,the Syn message 718 may include an MP_Join option. Additionally, sincethe cellular network interface may not be a preferred network interfacerelative to the Wi-Fi network interface, the Syn message 718 may includea ‘Backup’ flag, indicating that the cellular subflow would be a backup.

Similar to the subflow establishment message flow to establish the Wi-Fisubflow, the server 704 may respond by transmitting a Syn_Ack message720, which may also include an MP_Join option, to the client 702. Theclient 702 may then follow up with an Ack message 722, which may alsoinclude an MP_Join option.

Having successfully established MPTCP subflows between the client 702and the server 704 over both Wi-Fi and cellular data links, at thispoint data packets may be transmitted over either or both MPTCPsubflows.

As previously noted, such a scenario as illustrated in and describedwith respect to FIG. 7, in which a client includes both Wi-Fi andcellular network interfaces, of which both, one, or neither may beavailable at any given time, may be common for many mobile devices.Wi-Fi and cellular network interfaces may have disparate characteristicswhich may lead users of such devices to have use preferences withrespect to those network interfaces. For example, many cellular networksmay charge fees on a per data usage basis (i.e., may provide metereddata usage, e.g., in lieu of or in addition to a monthly subscriptionfee), whereas many Wi-Fi network providers may not charge fees on a perdata usage basis, but rather may provide unlimited data usage (e.g., fora monthly subscription fee). While it will be recognized that suchcharacteristics are not universal features of cellular and Wi-Finetworks, because such characteristics may be common in many cases, manymobile applications may prefer to use cellular networks primarily orexclusively as a backup communication path, while Wi-Fi may be apreferred communication path when available.

Fixed endpoints may not have the same priorities. For example, a fixedendpoint with at least one wired network interface may not havesignificant variation in availability of its network interface(s), dueboth to the substantially stationary nature of the fixed endpoint andthe higher degree of reliability/availability typically provided by awired network interface relative to wireless network interfaces.Further, regardless of the fixed versus mobile nature of a remoteendpoint of an MPTCP connection, a local endpoint may not be aware ofdifferences in use preferences of the remote endpoint between differentsubflows. Accordingly, at least in some cases, when an MPTCP connectionis established between a mobile endpoint and a fixed endpoint, it may bepreferable to enable the mobile endpoint to dictate which of its networkinterfaces (and thus which MPTCP subflow) to use as the active path andwhich as the backup path. Correspondingly, it may not be desirable for afixed endpoint to dictate the constraints of an MPTCP connection with amobile endpoint.

It is also worth noting that more generally, regardless of whether fixedor mobile, a local endpoint may not be aware of any differences in usepreferences of a remote endpoint between different subflows. Thus ifboth endpoints of an MPTCP connection are mobile, each side may have usepreferences unknown to the other. For example, one endpoint may knowwhich subflows use its cellular network interface and which subflows useits Wi-Fi network interface, but may not be aware of which subflowscorrespond to which network interfaces of the other endpoint, and viceversa.

It should be recognized that the above described examples relating tofixed- and mobile-endpoint network interface characteristics and usepreferences are provided by way of explanation and should not beconsidered limiting to the disclosure. Any number of additional oralternative use preference profiles, network interface combinations,and/or variations in fixed & mobile endpoint combinations are alsopossible. However, these examples are illustrative, more generally, ofthe potential advantages of introducing additional elements ofconnection control and configuration to MPTCP connections.

For example, it may be desirable to provide a way for one or bothendpoints to assert control over an MPTCP connection. In such a case, acontrolling endpoint may be able to create new subflows, dictatepriority (e.g., active/primary versus backup/secondary) of subflows, andcontrol data transmission flow across primary and backup subflows tofacilitate faster transitions to a functional subflow from anon-functional subflow. A non-controlling endpoint, in contrast, may not(e.g., may be prevented from or not have permission to) initiate newsubflows or modify subflow priorities, and may follow the lead of thecontrolling endpoint with respect to data transmission flow acrossprimary and backup subflows. For example, a non-controlling endpoint maymonitor/determine on which MPTCP subflow data has most recently beenreceived, and may transmit data over the MPTCP subflow on which data hasmost recently been received.

Thus, in an exemplary scenario in which a client (such as client 702) isa mobile client having both a Wi-Fi and a cellular network interface,while a server (such as server 704) is a fixed server having a wirednetwork interface, the client might assert control over the MPTCPconnection, while the server might not assert control over the MPTCPconnection. The client might in this case dictate that the Wi-Fi subflowwould be primary, and the server would not modify this priority.Further, the client might in this case choose whether or not toestablish a cellular subflow, while the server would not attempt toinitiate a subflow on the client's cellular network interface.Additionally, if the Wi-Fi network interface were to fail and the clienttransitioned to transmitting data on the (e.g., backup) cellularinterface subflow, the server would follow the client's lead and alsotransmit data on the cellular interface subflow, even if the server doesnot receive an indication to elevate the priority of that subflow (e.g.,due to unreliability of a priority modification option).

It may also be possible to provide a way for multiple endpoints toassert control over an MPTCP connection. This may be desirable, forexample, in the above-described exemplary scenario in which bothendpoints are mobile and have their own unique use preferences regardingnetwork interfaces and corresponding subflows. In such a case, each sidemay be able to override any prior signaling of path priority anddemote/promote path priority. Thus, for instance, if a subflow is set upfrom one endpoint's Wi-Fi network interface to the other endpoint'scellular network interface, the receiving endpoint may prefer to demotethe priority of the subflow to backup if another subflow is availableover its Wi-Fi network interface.

More generally, if both endpoints assert control over an MPTCPconnection, both endpoints may be able to actively vote on subflowestablishment and path priorities. For example, both endpoints may beable to initiate subflows. Both endpoints may also or alternatively beable to demote subflows from primary to backup priority and promotesubflow priority from backup to primary (e.g., when no other path isavailable). Additionally, both endpoints may attempt to follow the otherendpoint's lead with respect to over which subflow data most recentlyarrived. In other words, each endpoint may monitor/determine on whichMPTCP subflow data has most recently been received, and may transmitdata over the MPTCP subflow on which data has most recently beenreceived whenever possible.

A further consideration with respect to subflow initiation may be thatmany mobile devices may reside behind network address translators(NATs). In such a case a mobile endpoint may not be able to directlyadvertise a local address for a remote endpoint to connect to usingMPTCP's ADD_ADDR option. Even if the endpoints use an out of bandmechanism for address discovery and NAT hole punching, it can becounter-productive for subflow creation to be dictated purely by theADD_ADDR option, as the end-host receiving the ADD_ADDR option andinitiating the connection may have no knowledge of the costcharacteristics of the remote endpoint's network interfaces (e.g.,wireless networks).

Accordingly, it may be preferable generally for mobile endpoints to bethe initiators of subflows, and it may be preferable generally for fixedendpoints not to be the initiators of subflows with mobile endpoints, asthey may not be aware of to which type of network interface (e.g., Wi-Fior cellular) the mobile endpoint is connected, even if they have out ofband mechanisms for discovering the mobile endpoints' translated/publictransport addresses. In a scenario in which a fixed endpoint wishes toinform a mobile endpoint of an additional address at which an MPTCPsubflow may be initiated, then, the fixed endpoint may send an ADD_ADDRoption to the mobile endpoint for the mobile devices to connect to.

Control of an MPTCP connection may be asserted in any of a variety ofways. As one possibility, assignment of control may be achieved through(e.g., hardwired) configuration of the endpoints. Thus, an endpoint maybe configured to be a master/controller of MPTCP connections (e.g., if amobile endpoint) for all MPTCP connections involving that endpoint, orto be a slave/non-controller of MPTCP connections (e.g., if a fixedendpoint) for all MPTCP connections (e.g., for which the remote endpointis configured to act as a master with respect to the MPTCP connection).As previously noted, hybrid fixed/mobile endpoints are also possible; insuch a case, configuration may be used to treat such a device as eithera mobile end-point or a fixed end point.

As another possibility, the MPTCP wire protocol may be used todynamically assign/assume controllership. For example, a subflowinitiator may initiate an MPTCP subflow with a Syn message having anMP_Capable option, such as Syn message 706 illustrated in FIG. 7. Whileit should be noted that alternate formats are also possible, onepossible exemplary format for the MP_Capable option is illustrated inFIG. 8.

The ‘version’ field illustrated as shown may in this case be set to 1.In version 1, flag ‘C’ may be used for declaringcontrollership/asserting master status of the MPTCP connection. In thiscase ‘C’ would be set to 1.

An MPTCP capable receiver of such an MP_Capable option may respond witha Syn_Ack which also includes an MP_Capable option, such as Syn_Ackmessage 708 illustrated in FIG. 7. While again it should be noted thatalternate formats are also possible, as one possibility this responseMP_Capable option may have the exemplary format illustrated in FIG. 9.

If the receiver of the MP_Capable option is a fixed endpoint (orotherwise does not wish to assert control over the MPTCP connection),that endpoint may stop initiating subflows. That endpoint may also nolonger set path priorities, and may follow the lead of the controllingendpoint when transitioning from one subflow to another. Such anendpoint may signal its non-controllership/assert slave status of theMPTCP connection by not setting the ‘C’ flag (i.e., setting the ‘C’ flagto 0) in its MP_Capable response if it supports version 1, and bysetting the version field to 1.

If the receiver of the MP_Capable option is mobile endpoint (orotherwise does wish to assert control over the MPTCP connection), thatendpoint may understand that the remote endpoint also wishes to assertcontrol over the connection (e.g., because the remote endpoint may alsobe mobile), and may collaboratively allow path priorities to be promotedor demoted. Similarly, both endpoints may follow each others' lead indata transmission when switching from one subflow path to anothersubflow path. Such an endpoint may signal its controllership/assertmaster status of the MPTCP connection by setting the ‘C’ flag (i.e.,setting the ‘C’ flag to 1) in its MP_Capable response if it supportsversion 1, and by setting the version field to 1.

Embodiments of the present disclosure may be realized in any of variousforms. For example some embodiments may be realized as acomputer-implemented method, a computer-readable memory medium, or acomputer system. Other embodiments may be realized using one or morecustom-designed hardware devices such as ASICs. Still other embodimentsmay be realized using one or more programmable hardware elements such asFPGAs.

In some embodiments, a non-transitory computer-readable memory mediummay be configured so that it stores program instructions and/or data,where the program instructions, if executed by a computer system, causethe computer system to perform a method, e.g., any of a methodembodiments described herein, or, any combination of the methodembodiments described herein, or, any subset of any of the methodembodiments described herein, or, any combination of such subsets.

In some embodiments, a device (e.g., a UE) may be configured to includea processor (or a set of processors) and a memory medium, where thememory medium stores program instructions, where the processor isconfigured to read and execute the program instructions from the memorymedium, where the program instructions are executable to implement anyof the various method embodiments described herein (or, any combinationof the method embodiments described herein, or, any subset of any of themethod embodiments described herein, or, any combination of suchsubsets). The device may be realized in any of various forms.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

We claim:
 1. An electronic device, comprising: one or more networkinterfaces; and one or more processors operably coupled to the one ormore network interfaces; wherein the one or more processors and the oneor more network interfaces are configured to: establish a multipathtransmission control protocol (MPTCP) connection with a remote endpoint,wherein the MPTCP connection comprises at least a first MPTCP subflowand one or more second MPTCP subflows, wherein the first MPTCP subflowcorresponds to a first radio access technology (RAT) and the one or moresecond MPTCP subflows correspond to one or more respective second RATs,and wherein the electronic device is configured to act as master withrespect to the MPTCP connection; and wherein, in being configured to actas master with respect to the MPTCP connection, the electronic device isconfigured to: designate the first MPTCP subflow as an active subflowthat is used as the default subflow for transmission during the MPTCPconnection; and designate the one or more second MPTCP subflows as oneor more respective backup subflows that are used for transmission duringthe MPTCP connection when the active subflow fails.
 2. The electronicdevice of claim 1, wherein the first RAT is a wireless local areanetwork (WLAN) RAT, and wherein the one or more second RATs include acellular RAT.
 3. The electronic device of claim 1, wherein the one ormore processors and the one or more network interfaces are furtherconfigured to: detect that a transmission to the remote endpoint usingthe first MPTCP subflow has failed; and at least in part in response todetecting that the transmission to the remote endpoint using the firstMPTCP subflow has failed, promote a particular subflow of the one ormore second MPTCP subflows to be the active subflow, and demote thefirst MPTCP subflow to be one of the backup subflows.
 4. The electronicdevice of claim 1, wherein designating a second MPTCP subflow as abackup subflow comprises including a “backup” flag in a messagetransmitted to the remote endpoint using the second MPTCP subflow. 5.The electronic device of claim 1, wherein the electronic device ismobile, and wherein the remote endpoint is a fixed endpoint.
 6. Theelectronic device of claim 1, wherein the one or more processors and theone or more network interfaces are further configured to: receive atransmission from the remote endpoint via a particular second subflow ofthe one or more second MPTCP subflows; and at least in part in responseto receiving the transmission from the remote endpoint via theparticular second subflow, promote the particular second subflow to bethe active subflow and demote the first MPTCP subflow to be one of thebackup subflows.
 7. The electronic device of claim 6, wherein the one ormore processors and the one or more network interfaces are furtherconfigured to: receive an indication from the remote endpoint that theremote endpoint is also configured to act as master with respect to theMPTCP connection; and wherein promoting the particular second subflow tobe the active subflow and demoting the first MPTCP subflow to be one ofthe backup subflows is performed further based at least in part onreceiving the indication.
 8. An apparatus, comprising one or moreprocessors configured to cause a wireless device to: establish amultipath transmission control protocol (MPTCP) connection with a remoteendpoint, wherein the MPTCP connection comprises at least a first MPTCPsubflow and one or more second MPTCP subflows, wherein the first MPTCPsubflow corresponds to a first radio access technology (RAT) and the oneor more second MPTCP subflows correspond to one or more respectivesecond RATs, and wherein the wireless device is configured to act asmaster with respect to the MPTCP connection; and wherein, in beingconfigured to act as master with respect to the MPTCP connection, thewireless device is configured to: designate the first MPTCP subflow asan active subflow that is used as the default subflow for transmissionduring the MPTCP connection; and designate the one or more second MPTCPsubflows as one or more respective backup subflows that are used fortransmission during the MPTCP connection when the active subflow fails.9. The apparatus of claim 8, wherein the first RAT is a wireless localarea network (WLAN) RAT, and wherein the one or more second RATs includea cellular RAT.
 10. The apparatus of claim 8, wherein the one or moreprocessors are further configured to cause the wireless device to:detect that a transmission to the remote endpoint using the first MPTCPsubflow has failed; and at least in part in response to detecting thatthe transmission to the remote endpoint using the first MPTCP subflowhas failed, promote a particular subflow of the one or more second MPTCPsubflows to be the active subflow, and demote the first MPTCP subflow tobe one of the backup subflows.
 11. The apparatus of claim 8, whereindesignating a second MPTCP subflow as a backup subflow comprisesincluding a “backup” flag in a message transmitted to the remoteendpoint using the second MPTCP subflow.
 12. The apparatus of claim 8,wherein the wireless device is mobile, and wherein the remote endpointis a fixed endpoint.
 13. The apparatus of claim 8, wherein the one ormore processors are further configured to cause the wireless device to:receive a transmission from the remote endpoint via a particular secondsubflow of the one or more second MPTCP subflows; and at least in partin response to receiving the transmission from the remote endpoint viathe particular second subflow, promote the particular second subflow tobe the active subflow and demote the first MPTCP subflow to be one ofthe backup subflows.
 14. The apparatus of claim 13, wherein the one ormore processors are further configured to cause the wireless device to:receive an indication from the remote endpoint that the remote endpointis also configured to act as master with respect to the MPTCPconnection; and wherein promoting the particular second subflow to bethe active subflow and demoting the first MPTCP subflow to be one of thebackup subflows is performed further based at least in part on receivingthe indication.
 15. A non-transitory computer accessible memory medium,comprising program instructions that, when executed by a processor,cause an electronic device to: establish a multipath transmissioncontrol protocol (MPTCP) connection with a remote endpoint, wherein theMPTCP connection comprises at least a first MPTCP subflow and one ormore second MPTCP subflows, wherein the first MPTCP subflow correspondsto a first radio access technology (RAT) and the one or more secondMPTCP subflows correspond to one or more respective second RATs, andwherein the electronic device is configured to act as master withrespect to the MPTCP connection; and wherein, in being configured to actas master with respect to the MPTCP connection, the electronic device isconfigured to: designate the first MPTCP subflow as an active subflowthat is used as the default subflow for transmission during the MPTCPconnection; and designate the one or more second MPTCP subflows as oneor more respective backup subflows that are used for transmission duringthe MPTCP connection when the active subflow fails.
 16. Thenon-transitory computer accessible memory medium of claim 15, whereinthe first RAT is a wireless local area network (WLAN) RAT, and whereinthe one or more second RATs include a cellular RAT.
 17. Thenon-transitory computer accessible memory medium of claim 15, whereinthe program instructions are further executable to cause the electronicdevice to: detect that a transmission to the remote endpoint using thefirst MPTCP subflow has failed; and at least in part in response todetecting that the transmission to the remote endpoint using the firstMPTCP subflow has failed, promote a particular subflow of the one ormore second MPTCP subflows to be the active subflow, and demote thefirst MPTCP subflow to be one of the backup subflows.
 18. Thenon-transitory computer accessible memory medium of claim 15, whereindesignating a second MPTCP subflow as a backup subflow comprisesincluding a “backup” flag in a message transmitted to the remoteendpoint using the second MPTCP subflow.
 19. The non-transitory computeraccessible memory medium of claim 15, wherein the electronic device ismobile, and wherein the remote endpoint is a fixed endpoint.
 20. Thenon-transitory computer accessible memory medium of claim 15, whereinthe program instructions are further executable to cause the electronicdevice to: receive an indication from the remote endpoint that theremote endpoint is also configured to act as master with respect to theMPTCP connection; receive a transmission from the remote endpoint via aparticular second subflow of the one or more second MPTCP subflows; andat least in part in response to receiving the indication and receivingthe transmission from the remote endpoint via the particular secondsubflow, promote the particular second subflow to be the active subflowand demote the first MPTCP subflow to be one of the backup subflows.